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recovery,  and  prove  that  the  protocol  satisfies  hybrid  atomicity,  a  local  atomicity  property  that  combines  aspects  of 
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1.  Introduction 

Atomic  transactions  are  a  widely  accepted  mechanism  for  coping  with  failure!  and  concurrency  in  database  systems, 
both  distributed  and  centralized.  Many  algorithms  have  been  proposed  for  concurrency  control  and  recovery  [1]. 
Early  work  in  this  sea  considered  only  untyped  objects:  operations  were  either  left  uninterpreted,  or  were  treated 
simply  as  reads  or  writes.  Mote  recent  work  has  focused  on  typed  objects,  such  as  queues,  directories,  or  counters, 
that  provide  a  richer  set  of  operations.  Several  algorithms  have  been  proposed  to  enhance  concurrency  and  recovery 
by  exploiting  data  objects’  type-specific  properties  12. 13, 18, 22].  Most  of  these  algorithms  are  locking  schemes  in 
which  oonfbcts  ate  governed  by  some  notioo  of  commutativity:  lock  modes  for  commuting  operations  do  not 
conflict 

This  paper  presents  a  new  locking  algorithm  for  concurrency  control  aid  recovery  of  typed  data  objects.  As 
discussed  below,  our  algorithm  permits  more  concurrency  than  many  type-specific  locking  schemes  in  the  literature 
[2,5,13,18,22]:  our  algorithm  places  fewer  constraints  on  lock  conflicts,  thus  permitting  a  larger  set  of 
interleavings.  Moreover,  our  algorithm  is  “upwardly  compatible”  with  these  other  schemes  in  the  sense  that  they 
can  be  used  together  in  the  same  system  without  jeapordizing  serializability  or  recovery. 

In  most  of  the  type-specific  algorithms  in  the  literature,  lock  conflicts  are  governed  by  some  notion  of 
commutativity:  if  two  operations  commute,  their  locks  need  not  conflict  Informally,  this  condition  arises  in 
conventional  two-phase  locking  schemes  as  follows.  If  two  transactions  attempt  to  acquire  conflicting  locks,  one 
must  wait  for  the  other  to  complete.  The  indticed  delay  ensures  that  the  latter  is  serialized  before  the  former. 
Two-phase  locking  thus  determines  transaction  serialization  up  to  a  partial  order,  transactions  unrelated  by  the 
transitive  closure  of  this  lode  conflict  relation  may  be  serialized  in  an  arbitrary  aider.  Moreover,  such  unrelated 
transactions  may  be  serialized  in  different  orders  at  different  data  objects,  or  at  different  sites  in  a  distributed  system. 
If  the  operations  of  concurrent  transactions  commute,  then  all  such  local  orderings  are  equivalent  and  compatible 
with  a  global  total  serialization  ordering. 

The  basic  idea  behind  our  algorithm  is  quite  simple.  Transactions  arc  serializable  in  the  order  they  commit  As  pan 
of  each  transaction’s  commitment  protocol,  it  generates  a  timestamp  from  a  logical  clock,  and  distributes  that 
timestamp  to  the  objects  it  updated.3  Our  algorithm  augments  the  implicit  partial  order  induced  by  lock  conflicts 
with  the  explicit  total  aider  induced  by  transactions’  commit  timestamps.  By  making  the  serialization  order  explicit, 
we  can  replace  the  commutativity  requirement  with  a  weaker  notion,  which  we  call  dependency.  For  example,  our 
algorithms  permits  concurrent  transactions  to  enqueue  on  a  FIFO  queue,  even  though  the  enqueue  operations  do  not 
commute. 

Our  algorithm  is  quite  general:  it  works  for  arbitrary  data  types,  including  types  with  partial  and  run-deterministic 
operations.  Our  treatment  is  systematic:  necessary  and  sufficient  conditions  for  locks  to  conflict  are  derived  by 
analyzing  the  object’s  data  type  specification.  We  give  a  formal  characterization  of  our  notion  of  conflict,  and  we 
prove  our  algorithm  is  comet  Because  concurrency  control  and  recovery  interact  in  subtle  ways,  our  descriptions 
and  proofs  encompass  both  concurrency  and  recovery. 

Section  2  defines  our  model  of  computation,  and  Section  3  gives  a  formal  definition  of  atomicity.  Section  4 
describes  our  criteria  for  lock  conflict  and  Section  5  describes  our  algorithm  and  proves  it  correct  Section  6 
discusses  some  pragmatic  issues.  Finally,  section  7  closes  with  a  discussion  and  summary. 


*Tbe*e  commit  tnaeeumpt  ibodd  not  be  amfaeed  with  the  timeeumpe  need 
tmnmction*  in  mdaBacd  in  a  atdctHy  predefined  order. 
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2.  Modd  of  Computation 

Oar  model  of  [22, 23]  has  two  kinds  of  entities:  transactions  aid  objects.  Each  object  provides 

operations  that  cat  be  called  by  transactions  to  examine  and  modify  the  object’s  state.  These  operations  constitute 
the  sole  means  by  which  transactions  can  access  the  state  of  the  object  We  typically  use  die  symbols  P,  Q,  and  R 
for  transactions,  red  X,  Y,  and  Z  for  objects. 

Oar  modd  of  computation  is  event-based,  focusing  on  the  events  a  die  interlace  between  transactions  and  objects. 
There  are  fb«r  kinds  of  events  of  interest 

•  Invocation  events,  denoted  <inv,  X,  P>,  occur  when  a  transaction  P  invokes  an  operation  of  object 
X.  The  “inv”  field  includes  both  the  name  of  the  operation  and  its  arguments. 

•  Response  events,  denoted  <res,  X,  P>,  occur  when  an  object  returns  a  response  res  to  an  earlier 
invocation  by  transaction  Pof  an  operation  of  object  X. 

•  Commit  events,  denoted  <commit(t),  X,  P>,  occur  when  object  X  learns  that  transaction  P  has 
committed  with  timestamp  t  Timestamps  are  taken  from  a  countable,  totally  ordered  set 

•  Abort  events,  denoted  <abort,  X,  P>,  occur  when  object  X  teams  that  transaction  P  has  aborted. 

We  refer  to  commit  and  abort  events  collectively  as  completion  events.  We  say  that  event  <e,  X,  P>  involves  X  and 
P. 

We  introduce  mm  notation  here.  The  symbol  denotes  concatenation  of  sequences,  and  the  symbol  “A” 
*•«•*  the  empty  sequence.  If  H  is  a  sequence  of  events  and  X is  a  set  of  objects,  we  define  HLT (“H  restricted  to 
X')  to  be  the  subsequence  of  H  consisting  of  the  events  involving  objects  in  X.  If  Xis  a  set  of  transactions,  we 
define  HI/* similarly.  If  X  is  an  object  and  P  is  a  transaction,  we  write  HfX  for  H1{X},  and  HD*  for  H1{P}.  We 
define  committed(H)  to  be  the  set  of  transactions  for  which  commit  events  occur  in  H,  and  aborted(H)  to  be  die  set 
of  transactions  for  which  abort  events  occur.  We  also  define  completed \H)  to  be  commitaed(H)  u  aborted(H),  the 
set  of  transactions  that  commit  or  abort  in  H. 

Not  all  sequences  of  events  make  sense  as  computations.  For  example,  a  transaction  should  not  commit  at  some 
objects  and  abort  at  others,  or  commit  with  different  timestamps  at  different  objects.  To  capture  these  constraints, 
we  introduce  a  set  of  well-formedness  constraints.  A  well-formed  sequence  of  events  is  calfed  s  history.  We  divide 
our  well-formedness  constraints  into  two  parts:  constraints  on  the  execution  of  individual  transactions,  and 
constraints  on  the  timestamps  that  can  appear  in  commit  events.  Individual  transactions  are  constrained  as  follows: 

•  Each  transaction  P  must  wait  for  the  response  to  its  last  invocation  before  invoking  the  next  operation, 
and  an  object  can  generate  a  response  for  P  only  if  P  has  a  pending  m vocation.  More  precisely,  let 
op-events(H/P)  be  the  subsequence  of  HIP  consisting  of  all  invocation  and  response  events;  op- 
events(HIP)  must  consist  of  an  alternating  sequence  of  invocation  and  response  events,  beginning  with 
an  invocation  event.  In  addition,  an  invocation  event  and  the  immediately  succeeding  response  event 
must  involve  the  same  object 

•  Each  transaction  P  caa  commit  or  abort  in  H,  but  not  both;  i.c.,  comniittad(HF)  n  abortedfHIP)  -  0. 

•  A  transaction  P  cannot  commit  if  it  is  waiting  for  the  response  to  an  invocation,  and  cannot  invoke  any 
operations  after  it  commits.  More  precisely,  if  Pecoaunined(f9),  then  HP  consists  of  op-eventstHD*) 
fofiowed  by  wtne  number  of  commit  events,  and  op-evente(HffO  ends  in  a  mpaBW  event 

These  ratirictfc—  an  tfirartions  are  intended  to  model  the  typical  use  of  transactions  in  easting  systems.  A 
transaction  executes  by  invoking  operations  on  objects,  receiving  results  whin  the  operations  finish.  Since  we 
disallow  concurrency  within  a  transaction,  a  transaction  is  permitted  at  most  one  pending  invocation  at  any  time. 
After  receiving  a  response  from  all  invocations,  a  transaction  can  commit  at  one  or  mare  objects.  A  transaction  is 
not  allowed  to  coomit  at  some  objects  and  abort  at  others;  this  requirement,  catted  atomic  commitment,  can  be 
implemented  using  weft-known  commitment  protocols  [7,  IS,  19]. 
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There  are  two  additional  constraints,  which  simply  state  that  the  timestamps  chosen  for  transactions  are  unique,  and 
that  a  transaction  chooses  only  ooe  timestamp. 

•  Any  two  commit  events  in  H  for  the  same  transaction  have  the  same  timestamp. 

•  Any  two  commit  events  in  H  for  different  transactions  have  different  timestamps. 

We  (dace  few  restrictions  on  aborted  transactions;  for  example,  a  transaction  can  continue  to  invoke  operations  after 
it  has  aborted.  We  have  two  reasons  for  avoiding  additional  restrictions.  First,  we  have  no  need  far  them  in  our 
analysis.  Second,  and  more  important,  additional  restrictions  might  be  too  strong  to  model  systems  with 
orphans  [6, 16],  and  we  would  like  our  results  to  be  as  generally  applicable  as  possible. 

3.  Atomicity 

In  this  section  we  define  atomicity  and  several  related  properties.  The  definitions  are  abstracted  from  [22, 23]. 
Unlike  many  earlier  models  that  classify  operations  only  as  reads  or  writes,  our  model  emphasizes  abstraction,  in 
particular  data  abstraction.  Atomicity  is  defined  in  terms  of  objects’  specifications,  so  that  transactions  are  atomic  if 
their  execution  appears  to  be  serializable  and  recoverable  to  transactions,  given  only  the  specifications  of  the 
objects.  For  example,  a  system  may  be  atomic  at  one  level  of  abstraction  and  nan-atomic  at  lower  levels. 

3.1.  Specifications 

Each  object  has  a  serial  specification,  which  defines  its  behavior  in  the  absence  of  concurrency  and  Mures.  An 
object’s  serial  specification  is  a  set  of  operation  sequences.  An  operation  is  a  pair  consisting  of  an  invocation  and  a 
matching  response.  In  addition,  an  operation  identifies  the  object  on  which  it  is  executed.  We  often  speak 
informally  of  an  “operation”  on  an  object,  as  in  “the  enq  operation  on  a  queue  object.”  An  operation  in  our  formal 
model  is  intended  to  represent  a  single  execution  of  an  “operation”  as  used  in  the  informal  sense.  For  example,  the 
following  might  be  an  operation  (in  the  formal  sense)  on  a  queue  object  X: 

X:[Enq(3),Ok] 

This  operation  represents  an  execution  of  the  Enq  operation  of  X  with  argument  “3"  and  result  “Ok."  For  brevity, 
we  often  say  that  an  operation  sequence  is  legal  if  it  belongs  to  the  serial  specification  currently  of  interest. 

Each  object  also  has  a  behavioral  specification,  which  characterizes  its  behavior  in  the  presence  of  concurrency  and 
failures.  An  object’s  behavioral  specification  is  just  a  set  of  histories  that  contain  events  involving  that  object  only. 

3.2.  Global  Atomicity 

Informally,  a  history  of  a  system  is  atomic  if  the  committed  transactions  in  the  history  can  be  executed  in  some  serial 
order  and  have  the  same  effect  In  order  to  exploit  type-specific  properties,  we  need  to  define  serializability  and 
atomicity  in  terms  of  the  serial  specifications  of  objects. 

Since  serial  specifications  are  sets  of  operation  sequences,  not  sets  of  histories,  we  need  to  establish  a 
correspondence  between  histories  and  operation  sequences.  We  say  that  a  history  is  serial  if  events  for  different 
transactions  are  not  interleaved.  If  H  is  a  serial  history,  and  Pj, ....  Pn  are  the  transactions  in  H  in  the  order  in  which 
they  appear,  then  we  can  write  H  as  HIPj*..,*!!!?,,.  We  say  that  a  history  H  is  failure-free  if  aborted(H)  *  0.  Now, 
if  H  is  a  aerial  failure- free  history,  we  define  OpSeq(H)  (the  operation  sequence  corresponding  to  H)  as  follows.  For 
a  transaction  P{,  OpSeq(HlPi)  is  the  operation  sequence  obtained  from  MPj  by  pairing  each  invocation  event  with  its 
corresponding  termination  event,  and  discarding  commit  events  and  pending  invocation  events.  For  the  full  history 
H,  OpSeq(H)  is  defined  to  be  OpSeq(HIP))*...»OpSeq(HIPD). 

For  example,  if  H  is  the  serial  failure-free  history 
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<Enq(3),X,Q> 

<OtX,Q> 

<Commil(U)XQ> 

<DeqOAP> 

<3,X,P> 

<commit(t2)AP> 

then  OpScq(H)  is  the  opeiaboc  sequence 

X:[Enq(3),Ok] 

X:[Deq03] 

We  say  that  a  serai  failure-free  history  H  is  acceptable  at  X  if  OpSeq(HIX)  is  an  element  of  the  serial  specification 
of  X;  in  other  wads,  if  the  sequence  of  operations  in  H  involving  X  is  permitted  by  the  serial  qweifu^uion  of  X,  A 
serial  failure-free  history  is  acceptable  if  it  is  acceptable  at  every  object  X. 

Two  histories  H  and  K  ar t,  equivalent  if  every  transaction  performs  the  same  sequence  of  steps  in  each,  Le.,  if  HIP  * 
Tfirfnr  nnrj  ti—trtinn  P.If  H  is  a  history  and  T  is  a  total  order  on  transactions,  we  define  SerialQdX)  to  be  the 
serid  history  equivalent  to  H  in  which  transactions  appear  in  the  order  T.  Thus,  if  Pt.  P*  ire  the  transactions  in  H 
indie  order  17  then  SeriaKHJ)  »  HlPj«_*HPm. 

Let  T  be  a  total  ordering  of  to«n«aeHona  A  failure- free  history  H  is  serialiiable  in  the  order  T  if  Serial(H,T)  is 
acceptable-  In  other  words,  H  is  serializable  in  the  order  T  if,  according  to  the  serial  specifications  of  the  objects,  it 
is  permissible  for  the  transactions  in  H,  when  run  in  the  order  T,  to  execute  the  same  steps  as  in  H.  We  say  that  a 
More-free  history  H  is  serialiiable  if  there  exists  a  total  order  T  on  transactions  such  that  H  is  serializable  in  the 
order  T. 

Now,  define  permotteiUfO)  to  be  HfeommittedfH).  We  then  say  that  H  is  atomic  if  permanent(H)  is  serializable. 
Thus,  we  formalize  recoverability  by  throwing  away  events  for  non-committed  transactions,  and  requiring  that  the 
committed  transactions  be  serializable. 

For  example^  the  following  history  involving  a  firat-in-first-out  (FIFO)  queue  X  is  atomic: 

<Enq(l),  X,  P> 

<Q*.X.P> 

<E*1(2).X,Q> 

<Ok,  X,  Q> 

<Enq(3),  X,  P> 

<0k,  X,  P> 

<commit(2),  X,  P> 

<commit(l),  X,  Q> 

<Deq,X,R> 

<2,X,fc> 

<Deq,  X,  B> 

<1,X,R> 

<co»mit(5),  X.  R> 

The  hri—ry  commas  only  comraittrd  transactions,  and  is  serializable  in  the  onto  Q  followed  by  P  followed  by  R. 

ULocdAhaitfey 

The  definition  of  siamiody  pnem  above  i»  global:  it  applies  to  a  history  of  an  epritp  QSiem.  Tp  bu$l  systems  in  a 
mmrnm  fodnen.  it  is  fcapostagt  to  define  local  proper***  of  qtyppts  that  gHpntee  s  ^bep  global 
FnpwiJ  «eh  as  mmUly.  A  local  atomtoity  peppery  is  a  property  f  of  gygificjttioni  $  ojyectsmch  Qat  the 
foUowhig  is  tree:  if  As  gpacifiwuion  of  every  object  in  a  system  satisfies  f ,  that  evqy  history  in  $£■  system’s 
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behavior  is  atomic.  To  design  a  local  atomicity  property,  one  most  ensue  that  the  objects  agree  on  at  least  one 
serialization  order  for  die  committed  transactions.  This  problem  can  be  difficult  because  each  object  has  only  local 
information;  no  object  has  complete  information  about  the  global  computation  of  the  system.  As  illustrated  in 
[22, 23],  if  different  objects  use  "correct”  but  incompatible  concurrency  control  methods,  non-serializable 
executions  can  result.  A  local  atomicity  property  describes  how  objects  agree  on  a  serialization  order  for  committed 
transactions. 

In  this  section  we  define  a  particular  local  atomicity  property,  which  we  call  hybrid  atomicity.  This  local  atomicity 
property  uses  the  timestamps  chosen  when  transactions  commit  to  constrain  each  object's  local  serialization  order. 
The  only  difficulty  is  that  an  object  does  not  know  what  timestamp  will  be  chosen  by  a  transaction  until  the 
transaction  commits.  This  difficulty  is  alleviated  by  placing  certain  simple  constraints  on  the  timestamp  generation 
method.  If  H  is  a  history,  define  precedes (H)  to  be  the  following  relation  on  transactions;  (P,Q)  e  precedes(H)  if 
and  only  if  there  exists  an  operation  invoked  by  Q  that  returns  a  result  after  P  commits  in  H.  The  relation 
precedes(H)  captures  potential  “information  flow"  between  transactions:  if  (P.Q)  e  precedes(H),  then  some 
operation  executed  by  Q  occurred  in  H  after  P  committed,  hence  Q  may  have  acquired  a  lock  released  by  P,  which 
would  imply  that  Q  must  be  serializable  after  P. 

Now,  let  73(H)  be  die  partial  order  on  transactions  defined  by  (P.Q)  e  TS(H)  if  P  and  Q  commit  in  H  and  the 
timestamp  for  P  is  less  than  the  timestamp  far  Q.  We  require  the  timestamp  generation  method  to  satisfy  the 
following  constraint:  the  timestamp  order  an  committed  transactions  must  be  consistent  with  the  precedes  order  at 
each  object  In  other  words,  precedes(HlX)  c  TS(H)  for  all  objects  X.  Informally,  this  constraint  requires  that  if  Q 
runs  at  X  and  sees  that  P  has  already  committed,  then  Q  must  choose  a  timestamp  greater  than  P’s.  This  constraint 
is  satisfied  by  timestamp  generation  algorithms  based  on  logical  clocks  [14],  and  by  algorithms  that  piggyback 
timestamp  information  on  the  messages  of  a  commit  protocol. 

A  history  H  is  hybrid  atomic  if  permanent(H)  is  serializable  in  the  order  TS(H).  (Notice  that  TS(H)  defines  a  total 
order  on  committed(H).)  An  object  is  hybrid  atomic  if  every  history  permitted  by  its  behavioral  specification  is 
hybrid  atomic.  Hybrid  atomicity  is  a  local  atomicity  property  [22,23]: 

Theorem  1:  If  every  object  in  a  system  is  hybrid  atomic,  then  every  history  in  the  system’s  behavior  is 
atomic. 

As  an  aside,  we  remark  that  hybrid  atomicity  is  an  optimal  local  atomicity  property:  no  strictly  weaker  local 
property  suffices  to  ensure  global  atomicity  [22, 23]. 

3.4.  Online  Hybrid  Atomicity 

Our  algorithm  is  pessimistic:  it  permits  an  active  transaction  to  commit  whenever  it  is  not  executing  an  operation. 
The  notion  of  online  hybrid  atomicity  captures  this  property. 

If  H  is  a  history  and  C  is  a  set  of  transactions,  we  say  that  C  is  a  commit  set  for  H  if  committed(H)  c  C  and  C  n 
sborted(H)  «  0.  In  other  words,  C  is  a  set  of  transactions  that  have  already  committed  or  might  commit.  Now,  if  H 
is  a  history,  define  Knownffl)  «  Precedes(H)  u  TS(H).  Known(HIX)  captures  what  X  “knows”  about  the 
timestamp  order  on  all  transactions,  both  committed  and  active.  Each  object  must  then  be  prepared  for  active 
transactions  to  choose  timestamps  in  any  order  consistent  with  the  object’s  local  knowledge.  Thus,  we  say  that  a 
history  H  is  online  hybrid  atomic  at  X  if,  for  every  commit  set  C  for  H,  and  for  every  total  order  T  consistent  with 
Known(H),  H)C  is  serializable  in  the  order  T.  H  is  online  hybrid  atomic  if,  for  all  objects  X,  H  is  online  hybrid 
atomic  at  X. 


The  following  lemma  is  immediate: 
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Lmmi  2:  If  H  is  online  hybrid  atomic,  H  is  also  hybrid  atomic. 

The  algorithm  proposed  in  this  paper  guarantees  online  hybrid  atomicity. 

The  queue  history  shown  earlier  is  hybrid  atomic;  in  fact,  each  of  its  prefixes  is  online  hybrid  atomic.  In  a  prefix  in 
which  •***"  P  or  Q  does  not  commit,  Known(H)  is  empty,  but  the  history  is  serializable  in  either  order  (P  followed 
by  Q  or  Q  followed  by  P).  Once  P  and  Q  commit,  Known(H)  contains  the  pair  (Q.P).  Once  R  executes  an 
Known(H)  also  contains  the  pairs  (P.R)  and  (Q.R),  and  thus  defines  a  total  order  Q-P-R  an  the  three 
t—wartVw  for  a  prefix  containing  one  of  R’s  operations  to  be  online  hybrid  atomic,  it  needs  to  be  serializable  in 
the  order  Q-P-R,  which,  as  argued  earlier,  it  is. 

4.  Conflicts  and  Concurrency 

This  deacribes  our  criteria  for  lock  conflict.  We  begin  with  an  informal  overview  of  the  locking  protocol 
itself,  and  then  we  present  a  formal  definition  of  our  notion  of  dependency.  We  conclude  with  a  series  of  examples 
illustrating  how  dependency  applies  to  a  variety  of  common  data  types. 

4.1.  Overview 

Our  protocol  uses  an  approach  similar  to  typical  locking  protocoli:  an  operation  determines  whether  it  can  proceed 
based  on  whether  *****  active  transactions  have  executed  conflicting  operations.  However,  our  notion  of 
"conflicts”  is  less  restrictive  than  in  previous  work;  in  addition,  unlike  most  previous  work  we  describe  precisely 
bow  commits  and  shorts  of  transactions  are  handled. 

The  protocol  maintains  three  components  for  each  object. 

•  Each  tn»n««rtWi  has  an  intentions  list  consisting  of  the  sequence  of  operations  to  be  applied  to  the 
object  if  the  transaction  commits.  (As  defined  earlier,  each  operation  consists  of  an  invocation, 
argument  values,  termination  condition,  and  result  values.) 

•  The  object’s  committed  state  reflects  the  effects  of  committed  transactions.  For  now,  it  is  convenient  to 
treat  the  committed  state  as  if  it  were  simply  the  intentions  lists  for  the  committed  transactions,  arranged 
in  timestamp  order.  In  section  6,  we  describe  a  more  compact  and  efficient  representation. 

•  A  set  of  locks  associates  each  operation  with  the  set  of  active  transactions  that  have  executed  that 
operation.  Locks  we  related  by  a  symmetric  conflict  relation  whose  properties  are  discussed  in  the  next 
section.  We  allow  the  lock  conflict  relation  to  take  arguments  and  results  into  account,  although  it  is 
not  farced  to  do  so. 

When  a  transaction  invokes  an  operation,  it  first  constructs  a  view  by  appending  its  own  intentions  list  to  the 
committed  state.  It  then  chooses  a  result  consistent  with  the  view.  Before  appending  the  new  operation  to  its 
intentions  list,  however,  the  transaction  requests  a  lock  for  the  operation.  If  another  active  transaction  holds  a 
conflicting  lode,  the  lock  request  is  refused,  the  result  is  discarded,  and  the  invocation  is  later  retried.  (The 
invocation  may  return  a  different  result  when  it  is  retried.)  If  the  lock  is  granted,  the  operation  is  appended  to  the 
transaction’s  intentions  list  and  the  response  is  returned.  (If  the  lock  conflict  relation  being  used  does  not  take 
results  into  account,  the  lock  can  be  requested  before  choosing  the  response.)  When  s  transaction  commits,  its 
intentions  list  is  merged  into  the  committed  sane  in  timestamp  order.  When  t  transaction  commits  or  aborts,  its 
locks  are  released  and  its  intentions  list  is  discarded. 

As  m  example,  consider  the  history  involving  a  FIFO  queue  shown  earlier.  As  shown  below  in  Section  4.3, 
enqueue  operations  o*  a  FDRO  queue  need  not  conflict  Thus,  our  protocol  allows  concurrent  enqueues,  and  in 
particular  afcws  the  hietory  shown  earlier.  The  order  in  which  concurrently  enqueued  items  should  be  dequeued  is 
desmaiuad  by  the  commit  timestamps  chosen  by  the  concurrent  transactions.  Notice  that  enqueues  do  not  commute. 
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so  commutativity-based  protocol*  would  not  allow  the  same  history. 


42.  Conflicts  and  Concurrency 

Hie  constraint  governing  lock  conflicts  is  the  notion  of  dependency,  operations  p  and  q  cannot  execute 
concurrently  if  one  depends  on  the  other.  Let  Jt  be  a  binary  relation  between  operations,  and  let  A  be  an  operation 
sequence. 

DefWtioa  3:  A  binary  relation  /f  on  operations  is  a  dependency  relation  for  Serial  if  for  all  operation 
sequences  A  and  A,  and  all  operations  p,  such  that 

1.  A  •  *  and  A  •  p  are  legal,  and 

2.  for  all  4  in  A,  (4,  p)e  Jt 
A«p«*is  legal. 

In  other  words,  if  A  is  legal  after  A,  pin  legal  after  A,  and  no  operation  in  A  “depends  on”  p,  then  it  should  be  legal  to 
do  A  after  p. 

A  dependency  relation  Jt  is  minimal  if  there  is  no  If  that  is  also  a  dependency  relation.  We  will  see  that  an 
object  may  have  several  distinct  minimal  dependency  relations.  We  prove  in  Section  5  that  our  protocol  is  correct  if 
and  only  if  the  lock  conflict  relation  is  a  symmetric  dependency  relation. 

The  following  lemmas  describe  some  important  properties  of  dependency  relations. 

Lemma  4:  Let  D  be  a  dependency  relation,  A  an  operation  sequence,  and  kjmAkj  operation  sequences 
such  that  k»  kj  and  A  •  Aj  are  both  legal.  If  no  operation  in  kj  depends  on  an  operation  in  Aj  (Le.,  for  all 
qj  in  kj  and  q2  in  Aj,  (4 tjq£d  D),  then  A  •  Aj  •  Ay  is  legal. 

Proof:  By  induction  on  the  length  of  Aj.  The  result  is  immediate  if  A?  is  empty.  For  the  induction  step, 
assume  that  Aj  -  Aj*  «p,  and  that  the  theorem  holds  for  all  sequences  shorter  than  Aj.  The  sequence  h  •  k^ 
is  legal  as  a  prefix  of  A  •  Aj,  A  •  *2’  •  pis  legal  by  hypothesis,  and  A  •  A*’  •  k,  is  legal  by  the  induction 
hypothesis.  Since  no  operation  m  kj  depends  on  p,  A  •  kj'  •  p  •  A;  -  A  •  kj  •  kt  is  legal  by  Definition  3.  □ 

Definition  5:  A  subsequence  g  of  A  is  Jt- closed  if  whenever  g  contains  an  operation  q  of  A  it  also  contains 
every  earlier  operation  p  such  that  q  Jtp. 

Definition  6:  A  subsequence  g  of  A  is  a  f-viw  of  A  for  q  if  g  is  jP-dosed.  and  if  it  includes  every  p  in  A 
such  that  q /fp. 

The  next  lemma  is  die  key  to  proving  the  correctness  of  our  algorithm.  It  says  that  to  determine  whether  an 
operation  is  legal  after  a  sequence  of  operations,  it  suffices  to  test  whether  it  is  legal  after  a  subsequence  that 
constitutes  a  vP-view  for  the  operation. 

Lemma  7:  Let  jP  be  a  dependency  relation  for  Serial,  and  g  and  A  sequences  in  Serial  such  that  g  is  a 
jP-viewof  A  for  an  operation  q.  If  g  •  q  is  in  Serial,  so  is  A  •  q. 

Proof:  We  show  by  induction  on  the  number  of  operations  in  A  but  not  in  g  that  A  •  q  is  legal.  If  A  *  g,  the 
result  is  immediate.  Assume  g  is  missing  at  least  one  operation  of  A,  and  assume  the  result  for  views 
missing  fewer  operations.  Let  A  =  hj  •  p  •  A^  wherep  is  the  first  operation  in  A  but  not  in  g.  Let  g  =  A;  • 
g2,andg’»A/*p*g2. 

The  sequence  ht  •  p  is  legal  as  a  prefix  of  A,  and  ht  •  g2  •  q  *  g  •  q  is  legal  by  hypothesis.  Since  g  is  a 
^-viewof  A  for  q,  no  operation  in  g2*  q  depends  an  p,  thus  ht  •p*g2*4»g’  •  4  is  legal  by  Definition  3. 


Since  g'  is  a  jP-view  of  A  for  4,  g*  •  4  is  legal,  and  g*  is  missing  fewer  operations  of  A  than  g,  it  follows 
from  the  induction  hypothesis  that  A  •  4  is  legal.  □ 


43.  Examples 

The  defmition  of  a  dependency  relation  given  in  the  previous  section  is  not  constructive:  it  merely  gives  a  test  far 
whether  a  gives  relation  is  a  dependency  relation.  In  this  section  we  describe  one  way  of  deriving  dependency 
relations  mote  systematically  from  the  serial  specifications  for  objects,  and  give  some  examples  of  dependency 
relations  far  particular  types  of  objects. 

One  way  of  defining  a  dependency  relation  for  an  object  is  to  say  that  an  operation  depends  on  any  earlier  operations 
that  might  invalidate  it  Mote  precisely, 

Definition  S:  Operation  p  invalidates  operation  q  if  there  exist  operation  sequences  hj  and  h2  such  that  ht 
•  p  •  *2  and  hj  •  hj  •  q  are  legal,  but  hj  •  p  •  hj  •  q  is  not. 

Definition  9:  Define  the  relation  invalidated-by  to  contain  all  pairs  (qj>)  such  that/)  invalidates  q. 

The  following  theorem  shows  that  this  definition  yields  a  dependency  relation: 

Theorem  10:  Invalidated-by  is  a  dependency  relation. 

Proof:  If  not,  then  there  exist  sequences  A  and  k  and  an  operation  p  such  that  h  •  p  and  A  •  k  are  legal,  no 
operation  in  A  is  invalidated  by  p,  but  A  •  p  •  k  is  illegal.  Let  A*p*A’  •qbethe  shortest  illegal  prefix  of 
A  •  p  •  k.  The  sequence  A  •  k'  •  q  is  legal  as  a  prefix  of  A  •  A.  A  •  p  •  A*  is  legal  by  construction,  but  A  •  p  • 
k'  •  q  is  illegal,  hence  q  is  invalidated  by  p,  a  contradiction.  □ 

While  invalidated-by  is  a  dependency  relation,  it  need  not  be  a  minimal  dependency  relation. 

The  remainder  of  this  section  describes  dependency  relations  for  certain  simple  objects,  illustrating  how  die  notion 
encompasses  partial  operations,  non-deterministic  operations,  and  operations’  responses.  We  caution  the  reader  not 
to  confuse  dependency  relations  and  conflict  relations.  Dependency  relations  need  not  be  symmetric;  the  conflict 
relations  used  in  our  algorithm,  however,  must  be  symmetric.  A  conflict  relation  will  typically  be  constructed  by 
taking  the  symmetric  closure  of  a  dependency  relation. 

A  Fite  provides  Read  and  Write  operations: 

Rand  m  Operation  0  Raturu  (VaJ.ua) 

Nrlta  m  Opacat Joa (Valua) 

where  Read  returns  the  most  recently  written  value.  The  unique  minimal  dependency  relation  for  Hie  objects  is 
shown  in  Figure  4-1,  where  so  entry  indicates  that  the  row  operation  depends  on  the  column  operation  when  the 
indicated  condition  holds.  This  relation  is  the  invalidated-by  relation  for  a  Hie  object  In  this  example,  a  read 
operation  depends  an  a  write  operation  when  their  argument  values  are  distinct  Note  that  write  operations  do  not 
depend  on  one  another.  Thus,  our  protocol  can  allow  concurrent  writes;  when  this  happens,  later  transactions  will 
rend  the  value  written  by  the  transaction  with  the  later  commit  timestamp.  Our  protocol  dius  encompasses  and 
generalizes  the  Thomas  Write  Rule  [21]. 


Figure  4-1:  Minimal  Dependency  Relation  for  Hie 

A  FIFO  Queue  object  has  two  operations,  Enq  and  Deq,  where  Enq  places  an  item  at  the  end  of  a  queue,  and  Deq 
removes  and  return  the  item  from  the  front  of  the  queue.  (If  the  queue  is  empty,  Deq  hjqcks;  thus,  its  specification 
is  partial.)  FIFO  Queues  have  two  distinct  minimal  dependency  relations,  shown  in  Figures  4-2  apd  4-3.  The 
coerespondiiig  conflict  relations  (obtained  by  taking  the  symmetric  closures  of  the  dependency  relations)  impose 
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incomparable  constraints  on  concurrency.  In  Figure  4-2,  which  is  the  invalidated-by  relation  for  FIFO  Queues,  a 
Deq  operation  involving  a  given  item  depends  on  both  Enq  operations  involving  different  items  and  Deq  operations 
involving  die  same  item,  implying  that  Deq  cannot  execute  concurrently  with  other  Enq  or  Deq  operations,  but  Enq 
operations  can  execute  concurrently.  In  Figure  4-3,  Enq  operations  involving  different  items  depend  on  one  another, 
and  Deq  operations  involving  the  same  items  depend  on  one  another,  but  Deq  operations  do  not  depend  on  Enq 
operations,  and  vice-versa.  (It  may  seem  counter-intuitive  that  Deq  operations  do  not  need  to  depend  on  Enq 
operations;  however,  it  should  become  clear  when  we  present  our  protocol  why  this  is  so.)  With  the  dependency 
relation  in  Figure  4-3,  an  enqueuing  transaction  can  execute  concurrently  with  a  dequeuing  transaction  as  long  as  the 
latter  can  dequeue  items  enqueued  by  committed  transactions. 


Enq(v),Ok 

DeqO.v 

Enq(v’),Ok 

DeqO.v’ 

warn 

v=v’ 

Figure  4-2:  Fust  Minimal  Dependency  Relation  for  Queue 


Enq(v),Ok 

DeqO.v 

Enq(v’),Ok 

■SB 

DeqO.v* 

v=v* 

Figure  4-3:  Second  Minimal  Dependency  Relation  far  Queue 

Constraints  on  concurrency  can  often  be  relaxed  by  introducing  non -determinism  into  sequential  specifications.  A 
Semiqueue  provides  Ins  and  Rem  operations: 

In*  ■  Operation (It an) 

Im  ■  Operation  ()  Ratuastltw) 

Ins  inserts  an  item  in  the  Semiqueue,  and  Rem  non-deterministically  removes  and  returns  an  item  from  the 
Semiqueue.  Like  Deq,  Rem  returns  only  when  there  is  an  item  to  remove.  (There  may  be  an  additional  probabilistic 
guarantee,  not  captured  by  our  functional  specifications,  that  the  item  removed  is  likely  to  be  the  oldest  one.)  A 
Semi  queue  object  has  the  unique  minimal  dependency  relation  shown  in  Figure  4-4.  This  dependency  relation 
prevents  Rem  operations  that  return  the  same  items  from  executing  concurrently,  but  allows  Ins  operations  to 
execute  concurrently  with  Rem  operations,  and  with  one  another. 


Ins(v),  Ok 

I 

< 

Ins(v*),Ok 

RemO,  v* 

Figure  4-4:  Minimal  Dependency  Relation  for  SemiQueue 

An  Account  provides  Credit,  Post,  and  Debit  operations: 

Credit  ■  Operation (Dollar) 

Port  -  Operation (Poraont) 

Debit  -  Operation (Dollar)  Signal*  (Overdraft) 

Credit  increments  the  account  balance  by  a  specified  amount  Post  posts  interest;  for  example,  [Post(5),Ok] 
multiplies  the  account  balance  by  1.05.  Debit  attempts  to  decrement  the  balance.  If  the  amount  to  be  debited 
exceeds  the  balance,  the  operation  returns  with  an  exception,  leaving  the  balance  unchanged.  Account  has  a  unique 
minimal  dependency  relation  shown  in  Figure  4-5.  As  in  several  of  the  previous  examples,  this  relation  is  the 


invaiidaud-by  relation  for  Account  objects.  An  interesting  aspect  of  this  relation  is  that  it  enhances  concurrency  by 
taking  operations’  responses  into  account.  For  example.  Credit  locks  need  not  conflict  with  locks  for  successful 
debits,  although  they  must  conflict  with  locks  for  attempted  overdrafts,  because  increasing  die  account  balance 
cannot  invalidate  a  successful  debit,  but  it  can  invalidate  an  Overdraft  exception.  If  both  kinds  of  debit  operations 
were  treated  alike,  debits  and  credits  would  have  to  be  mutually  exclusive,  a  significant  cost  if  attempted  overdrafts 
were  infrequent.  An  example  implementation  of  Account  appears  in  the  appendix. 


Credit(n),Ok 

Post(n),Ok 

Debit(n),Ok 

Debit(n), Overdraft 

Credit(m),Ok 

Fost(m),Ok 

Debit(m),Ok 

true 

Debit(m)  .Overdraft 

true 

true 

Figure  4-5:  Minimal  Dependency  Relation  for  Account 


5.  A  Hybrid  Locking  Protocol 

This  section  presents  a  formal  description  of  our  locking  protocol,  together  with  its  proof  of  correctness.  The 
description  here  is  designed  to  emphasize  the  general  strategy  followed  by  the  protocol,  and  to  highlight  the 
differences  with  other  locking  protocols.  In  section  6,  we  discuss  some  issues  that  arise  when  designing  an  efficient 
implementation  of  this  protocol  for  a  particular  data  type.  In  die  appendix,  we  present  an  example  implementation 
of  an  Account  object,  illustrating  how  properties  of  the  data  type  can  be  used  to  design  efficient  implementations. 

Given  the  serial  specification  Serial  of  an  object  X,  the  protocol  described  below  ensures  that  all  histories  generated 
by  the  implementation  of  X  are  hybrid  atomic.  For  ease  of  exposition,  we  will  not  refer  specifically  to  X  unless 
necessary;  thus,  when  we  refer  to  an  “operation"  we  mean  an  operation  of  X,  and  similarly  forevents. 


5.1.  The  Protocol 

A  state  machine  is  an  automaton  given  by  a  set  of  states,  a  set  of  transitions,  an  initial  state,  and  a  partial  transition 
function  that  maps  (stale .transition)  pairs  to  states.  If  the  transition  function  is  defined  on  a  given  pair  (s,t),  we  say 
that  t  is  defined  in  s.  The  transition  function  can  be  extended  in  the  obvious  way  to  finite  sequences  of  transitions. 
We  say  dial  a  sequence  of  transitions  is  accepted  by  a  machine  M  if  it  is  defined  in  the  inirial  stale  of  M.  We  define 
the  language  of  a  machine  M  (denoted  L(M))  to  be  the  set  of  finite  sequences  of  transitions  that  are  accepted  by  M. 

The  protocol  is  described  by  a  state  machine  LOCK  whose  language  consists  of  a  set  of  event  sequences.  The 
machine  uses  a  particular  conflict  relation.  Conflict,  to  test  whether  one  operation  conflicts  with  another.  We 
assume  that  Conflict  is  symmetric.  To  describe  the  protocol,  however,  we  do  not  need  to  make  any  other 
assumptions  about  the  conflict  relation  used  by  the  protocol.  In  the  next  section  we  will  show  that  conflict  relations 
derived  from  dependency  relations  are  both  necessary  and  sufficient  to  ensure  correctness  of  the  implementation,  in 
the  sense  that  every  complete  history  in  L(LOCK)  is  hybrid  atomic. 

A  states  of  LOCK  consists  of  four  components:  spending,  sintentions,  s.committed,  and  sJborted.  Spending  is  a 
partial  function  from  transactions  to  invocation  events.  S.  intentions  is  a  total  function  from  transactions  to 
sequences  of  operations.  S.committed  is  a  partial  function  from  transactions  to  timestamps.  Saborted  is  a  set  of 
Iremt  (ions. 


S  pending  records  pending  invocations  for  transactions.  Since  each  transaction  is  initially  quiescent,  spending  is 


11 


undefined  for  all  transactions  in  the  initial  state  of  LOCK.  S intentions  records  the  sequence  of  operations  executed 
by  each  transaction.  In  the  initial  state  of  LOCK,  s.in tendons  maps  each  transaction  to  the  empty  sequence.  There 
are  no  'locks”  recorded  explicitly  in  this  formal  model  of  the  algorithm;  instead,  the  set  of  locks  held  by  a 
transaction  is  implicit  in  the  transaction’s  intentions  list  S.committed  allows  us  to  tell  which  transactions  have 
committed,  and  for  each  committed  transaction  records  its  timestamp.  S.committed  is  initially  undefined  for  all 
transactions.  ^aborted  records  the  set  of  transactions  that  have  aborted,  and  is  initially  empty. 

If  s  is  a  state  of  LOCK,  define  s .completed  to  be  sjtborted  u  {P I  sxommitted(P)  *  1) ;  s  .completed  thus  consists  of 
all  transactions  that  have  either  committed  or  aborted.  If  Q  *  s. completed,  define  View(Q^)  to  be  the  operation 
sequence  obtained  by  concatenating  the  intentions  lists  for  all  committed  transactions  in  rimmaamp  older,  and  then 
appending  the  intentions  list  for  Q.4 

The  transitions  of  LOCK  are  the  events  involving  X;  their  preconditions  and  postconditions  are  described  below. 
For  brevity,  we  assume  that  all  input  histories  are  well-formed.  (Well-formedness  could  be  checked  explicitly  by 
adding  more  state  components  and  preconditions.)  In  the  descriptions,  the  expression  m[a  ->  b],  where  m  is  a 
(possibly  partial)  function  from  domains  A  to  B,  ae  A,  and  be  B,  denotes  the  function  identical  to  m  except  at  a, 
,  which  it  maps  to  b. 

In  describing  transitions,  we  write  preconditions  and  postcondition!  for  events,  using  the  convention  that  s’  denotes 
the  state  before  the  indicated  event,  xnd  s  denotes  the  state  after  the  event  In  addition,  a  state  component  that  is  not 
mentioned  in  the  postcondition  for  an  event  is  assumed  to  be  unchanged  by  the  occurrence  of  that  event. 

Invocation,  commit,  and  abort  events  are  inputs  controlled  by  the  transactions;  thus,  their  preconditions  are  True. 
The  transition  for  each  event  is  quite  simple:  the  event  is  simply  recorded  in  the  state  of  LOCK. 

<i,X,Q> 

Postcondition: 

s.pending  a  s'.pending[Q  -*  i] 

<commit(t),X,Q> 

Postcondition: 

s.committed  =  s’.committed[Q  -» t] 

<abortX,Q> 

Postcondition: 

s.aborted  *  s’. aborted  u  (Q) 

Response  events  are  somewhat  more  complicated: 


*b  pool,  Vkw(Q4)  u  not  i  ttfumtx,  once  the  let  of  committed  tnmartionr  could  be  infinite.  h  every  reachable  Male,  however,  only 
flnitaty  mrety  trmaattirma  have  commincd.  to  View(Q,«)  ir  well-defined. 
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<rXQ> 

Precondition: 

s'.pending(Q)  *  ± 

Q  t  s' completed 

Let  q  »  <s’jjending(Q)/> 

Vkw(Q4’)  •  q  «  Serial 

for  all  transactions  Pc  I'xotnpleicdu  {Q}, 

and  for  all  operations  p  in  g’  intention  8(P), 
<P4>C  Conflict 


Postcondition: 

spending  -  s’.pending[Q  -» 1] 

g.  intentions  «  s’  Jnteations[Q  ->  s’.intentkna(Q)  •  q] 

To  return  a  response  to  a  transaction,  there  an  several  requirements.  First,  the  transaction  must  have  s  pending 
invocation.  Second,  the  transaction  must  not  have  already  completed.  Third,  the  operation  (consisting  of.  the 
<mvocation,  result>  pair)  must  be  legal  in  the  transaction’s  “view."  Finally,  the  operation  must  not  conflict  witfc 
any  other  operation  already  executed  by  another  active  transaction.  If  all  these  requirements  atpiqq^  the  response 
event  can  occur,  causing  the  pending  invocation  to  be  removed  from  the  state  and  the  intentions  hat  for  the 
transaction  to  be  updated  to  record  the  new  operation. 

Notice  that  a. intentions  is  retained  for  all  transactions,  including  committed  transactions.  Thus,  the  “committed 
irate’’  is  simply  the  intentions  lists  for  the  committed  transactions,  arranged  in  timestamp  order.  This  approach  is 
clearly  not  practical.  Nevertheless,  it  permits  us  to  describe  the  protocol  in  a  simple  and  general  manner.  Mother 
recovery  methods  seem  to  be  special  cases  of  this  use  of  intentions  lists,  in  the  sense  that  they  record  no  more 
information  about  the  past  in  the  state.  In  addition,  same  other  recovery  methods  seem  to  require  restricting 
concurrency  mane  than  is  needed  for  intentions  lists.  In  later  sections,  we  will  show  that  there  age  simple 
optimizations  that  can  he  used  in  real  implementations  that  make  it  pnaaihle  tn  itiarard  intentions  lists  for  ranemittiy! 
tHBSflCOOOS. 


SJ.  Correctness  Proof 

We  wish  to  prove  the  following  theorem: 

Theorem  11:  If  Conflict  is  a  dependency  relation,  then  every  history  in  L(LOCK)  is  hybrid  atomic. 

We  wiO  show  that  if  Conflict  is  a  dependency  relation,  then  every  history  in  L(LOCK)  is  online  hybrid  at 
X.  Given  Lemma  2,  this  suffices  to  prove  Theorem  11. 

We  start  with  a  simple  lemma  relating  the  state  of  LOCK  after  a  history  to  the  events  in  the  history;  the  proof 
involves  a  simple  induction  on  die  length  of  histories  in  L(LOCK),  aid  is  omitted. 

Lemma  12:  Let  H  be  a  history  in  L(LOCK),  let  s  be  the  state  of  LOCK  after  H,  and  let  Q 1*  a  transaction. 

The  following  properties  hold: 

•  OpSeqOflQ)  *  sintemions(Q). 

•  OpSeqCMQ)  ends  in  the  invocation  mat  <i,X,Q>  <=>  s.pending(Q)  -  i. 

•  <commit(t),X,Q>  appears  in  H  «*  sxomraittstKQ) »  L 

•  aboned(H)  ■  sjborted. 

The  next  lemma  shows  that  active  transactions  do  not  conflict 

Lamma  13:  La  H  he  a  history  in  L(LOCK),  and  let  s  he  d*  stgtp  of  LQC*  ffter  H.  If  P  *  Q,  P  c 
Compieted(H).  and  Q  a  Completed(H),  than  no  operation  in  s.miwiiioQSiff*)  coqJBicy  aq  qgaagfcn  in 
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Prooft  An  easy  induction  oc  tbe  length  of  H.  □ 

The  next  lemma  shows  a  basic  property  of  two-phase  locking.  It  says  that  if  two  transactions  are  concurrent  (neither 
commits  before  the  other  executes  an  operation),  then  there  are  do  lock  conflicts  between  them. 

Lemma  14:  Let  H  be  a  history  in  L(LOCK).  If  P  and  Q  are  transactions  such  that  P#Q,  Pc  Aborted(H). 

>  Q  C  Abosted(H),  (P.Q)  c  Precedes#!).  and  (QJ0  C  Precedes(H).  then  no  operation  in  OpSeq(HlP) 

conflicts  with  an  operation  in  OpSeq(H)Q). 

Proof:  We  make  use  of  the  previous  lemma.  Let  G  be  the  largest  prefix  of  H  that  does  not  contain  a 
commit  event  for  P  or  Q,  and  let  s  be  tbe  stale  of  LOCK  after  G.  Neither  P  nor  Q  is  in  Completed(G). 
Therefore,  by  Lemma  13,  no  operation  in  s.mtentions(P)  conflicts  with  an  operation  in  s.intentions(Q).  By 
Lemma  12,  OpSeq(GIP)  ■  sJntenth)ns(P)  and  OpSeq(G)Q)  -  s.intcntionsfQ),  and  consequently  no 
operation  in  OpSeq(GlP)  conflicts  with  an  operation  in  OpScq(GIQ). 

; 

We  now  claim  that  OpSeq(GIF)  ■  OpSeq(HIP)  and  OpSeq(GIQ)  ■  OpScq(H)Q).  Since  no  operation  in 
OpSeq(GIP)  conflicts  with  an  operation  in  OpSeq(GIQ),  this  suffices  to  prove  the  lemma.  We  show  the 
claim  by  contradiction.  We  consider  P,  tbe  proof  for  Q  is  symmetric.  Suppose  OpSeqfGlP)  * 
OpSeq(HIP).  Then  OpSeq(HIP)  is  longer  than  OpSeq(GIP);  let  <i/>  be  the  first  operation  that  occurs  in 
,  OpSeq(HlP)  that  does  not  occur  in  OpSeq(GIP).  It  follows  that  die  event  <r,X,P>  occurs  in  H  and  not  in 

G.  Furthermore,  <r,X,P>  must  occur  in  H  after  a  commit  event  for  either  P  or  Q,  since  G  is  the  largest 
prefix  of  H  that  does  not  contain  a  commit  event  for  either  P  or  Q.  The  event  <r,X,P>  cannot  occur  after  a 
commit  event  for  P,  since  H  is  well-formed;  therefore,  it  occurs  after  a  commit  event  for  Q.  This  implies, 
however,  that  (Q,P)  e  Prccedes(H),  which  contradicts  one  of  the  hypotheses  of  the  lemma.  □ 

The  next  lemma  is  needed  to  show  that  View(Q,s)  contains  enough  information  to  compote  the  result  of  an 
operation. 

Lemma  15:  Let  H  be  a  history  in  L(LOCK),  and  let  S|{  he  the  state  of  LOCK  after  H.  Let  C  be  a  commit 
setforH,andletPbean  active  transaction  in  C,  Le.,  P  6  C  -  Conunitted(H).  Finally,  let  T  be  a  total 
order  on  transactions  consistent  with  Known(H)  such  that  (Q,P)  e  T  for  every  Q  e  Cotnmitted(H).  Then 
ViewfP.Sjj)  is  a  Conflict- dosed  subsequence  of  OpSeq(Serial(HJC,T)). 

Prooft  We  first  argue  that  View(P^  is  a  subsequence  of  OpSeq(Serial(HIC,T));  we  then  show  that  it  is 
CoqfUcr-dosed. 

ViewfP.Sjj)  is  constructed  by  appending  sH.intentions(Q),  for  each  Q  in  Committed(H),  indexed  in  the 
order  given  by  SjjXommittodfQ),  and  then  appending  sHintentions(P).  By  Lemma  12,  SjjintentionsfR)  « 
OpSeq(HIR)  for  every  transaction  R,  and  the  order  given  by  sHxommitted(Q)  is  the  same  as  TS(H).  Thus, 
ViewCP.Sn)  ■  OpSeq(HIQ,)  •  ...  •  OpSeqfHlQJ  •  OpSeqCHIP),  where  are  die  transactions  in 

Committed#!)  in  die  order  specified  by  TS(H).  Since  T  is  consistent  with  TS(H)  aid  (Q.P)  e  T  for  every 
Q  e  Committed#!).  the  operations  in  View(P,sH)  appear  in  the  same  order  in  OpSeqlSeriaKHIC.T)). 
Thus.  ViewCP^)  is  a  subsequence  of  OpSeq(SeriaJ(H)C  ,T». 

Now  we  show  that  View(P^H)  is  a  ConflicKiosed  subsequence  of  OpSeq(Serial(HJC,T)).  We  proceed  by 
induction  on  the  length  of  H.  The  basis  case,  when  H  *  A,  is  immediate. 

For  the  induction  step,  suppose  H  *  A.,  and  assume  that  the  theorem  holds  for  all  histories  in  L(LOCK) 
that  are  shorter  than  H.  Then  H  ■  K  •  e  for  some  history  K  in  L(LOCK)  and  some  event  e.  Let  Sg  be  the 
stale  of  LOCK  after  K.  By  induction,  the  lemma  holds  for  K  and  Sg. 

First,  note  that  Precedes(K)  c  Precedes#!),  TS(K)  c  TS(H),  Committed(K)  c  Oommitted(H).  and 
Aborted(K)  c  Aborted(H).  Thus,  CandT  satisfy  the  conditions  of  the  lemma  for  K.  By  induction, 
ViewfP.ig)  is  a  Conflict- closed  subsequence  of  OpSeq(SeriaKKIC,T)).  There  are  three  cases  to  consider, 
depending  on  the  type  of  e. 

1.  Suppose  e  is  an  invocation  or  abort  event  for  some  transaction  R.  Then  Sjj  intentions  ■ 
tgJntentkns,  and  SH-committod  -  Sg  .committed.  Thus,  View(P,iH)  -  View#\ig).  If  e  is  an 
abort  event,  R«  C.  Otherwise,  note  that  OpSeq  throws  awsy  pending  invocation  events.  In  either 


case,  OpSeq(Serial(HlC,T))  *  OpSeq(Serial(KJC,T)).  The  result  follows  from  the  induction 
hypothesis. 

2.  Suppose  gist  commit  event  for  some  transaction  R.  Since  OpSeq  throws  away  commit  and  short 
events,  OpSeq(Serial(H)C,T))  -  OpSeq(Serial(KlC,T)).  In  addition,  View(P3H)  is  obtained  from 
ViewfP^)  by  inserting  OpSeq(HR)  in  the  position  determined  by  the  timesttmp  for  R.  To  Aow 
that  View(P,SH)  is  a  Conflict- dosed  subsequence  of  OpSeqfSeriaKHC.T)),  we  must  show  thtt  for 
every  operation  in  ViewCP^n),  every  earlier  conflicting  operation  from  OpSeq(SeriaKH)C,T»  is 
also  in  ViewfR^).  By  the  induction  hypothesis,  this  is  true  for  operations  that  are  hi  both 
View(P^n)  and  ViewCP^).  The  operations  that  are  in  ViewCP^  but  not  hi  ViewfP^)  are  the 
operations  in  sHJntention^R).  S  impose  an  operation  r  in  OpSeq(SeriaKH)C,T))  precedes  some 
operation  q  in  s„  Jntentkma(R)  and  conflicts  with  it,  aid  let  S  be  the  transaction  thtt  executed  r. 
Then  by  i^wim  14  and  the  constraints  on  T,  <SJt>  €  Piecedes(H).  By  the  definition  of 
Ptecedea(H),  S  e  Committed(H),  aid  thus  r  appears  in  ViewfP^n). 

3.  Finally,  suppose  that  t  is  a  response  event  If  P  «  R  die  result  follows  from  the  induction 

hypothesis  and  die  precondition  for  e,  since  the  operation  added  to  sHdntentions(P)  by  e  cannot 
conflict  with  operations  executed  by  active  transactions,  and  all  other  operations  in 
OpSeq(Sarial(HlC,T»  are  in  View(P,sH). 

tf  P  and  Rare  distinct,  then  View(P,sH)>»View(P,sK).  IfRa  C,  then  OpSeq(Serial(H)CfT))  * 
OpSeq(Serial(KlC.T»,  and  the  result  follows  by  induction.  Otherwise,  OpSeq(Scrial(H)C,T)) 
differs  from  OpSeq(Serial(KIC,T))  in  thtt  it  contains  an  extra  operation  for  R.  Since  H  is  well- 
formed,  R  «  Committed(H).  By  Lemma  14,  an  operation  executed  by  R  conflicts  with  an 
operation  executed  by  another  transaction  S  only  if  <SJt>  e  Precedes(H).  Therefore,  every 
operation  in  OpSeq(Serial(HlC,T))  that  conflicts  with  an  operation  q  executed  by  R  appears 
before  q.  The  result  follows  by  induction. 

□ 

Now  we  are  ready  to  prove  die  main  result 

Theorem  16:  Suppose  H  is  a  history  in  L(LOCK),  and  suppose  Conflict  is  a  dependency  relation.  Then  H 
is  online  hybrid  atomic  at  X. 

Preeft  The  proof  proceeds  by  induction  on  the  length  of  H.  The  basis  case,  when  H  -  A,  is  immediate. 

For  the  induction  step,  suppose  H  *  A,  and  assume  the  result  for  all  histories  in  L(LQCK)  shorter  than 
K.  Then  H  ■  K  •  e  for  some  history  K  in  L(LOCK)  and  some  event  e.  Since  K  is  shorter  than  H,  the 
theorem  holds  for  K. 

Note  that  all  events  in  H  (red  K)  involve  only  X;  thus,  H  *  HOC. 

Let  sK  be  the  state  of  LOCK  after  K. 

Now,  let  C  be  a  commit  set  for  H,  and  let  T  be  a  total  order  on  transactions  consistent  with  Known(H).  To 
show  that  H  is  online  hybrid  atomic  at  X,  it  suffices  to  show  that  HC  is  serializable  in  the  order  T,  i.e., 
thatOpSeq(Serial(H)C,T»  is  legal. 

First,  note  that  Precedes(K)  c  Precedes(H),  TS(K)  c  TS(H),  Committed(K)  c  Committed(H),  and 
AbortedCK)  c  AbonedfH).  Thus,  C  and  T  satisfy  die  conditions  of  the  definition  of  on-line  hybrid 
atomicity  for  K.  There  an  now  two  cases,  depending  on  the  type  of  e. 

1.  Suppose  e  is  a  commit,  abort,  or  invocation  even.  Note  thtt  OpSeq  throws  away  pending 
invocation  events,  commit  events,  and  abort  events.  Thus,  OpSeq(Serial(H)C,T))  ■ 
OpSeq(Serial(K)C,T)).  Since  the  theorem  holds  for  K,  it  also  holds  for  H. 

2.  Suppose  that  e  is  a  response  event  <r^P>.  This  is  the  difficult  case.  Note  tint  if  Pc  CthenHIC 
■  KJC,  and  the  result  follows  from  the  induction  hypothesis.  So  assume  that  Pe  C. 

Ltt  Active  m  C  -  Commiued(H).  The  sequence  OpScq(Seritt(H)C,T))  can  be  written  as  h,  • 
OpSeqCHP)  •  h#  where  k,  -  QpSeqfseriaKHIC,))  and  h,  -  OpSetKeerialfHCj)),  and  C,  and  Cj 


are  chosen  such  that  Comnrined(H)  c  Ct>  Cj  c  Active,  and  P  c  C,  u  The  aequencea  and 
Aj  respectively  contain  the  operations  of  transactions  ordered  before  and  after  P  by  T.  C,  contains 
Commiaed(H)  because  T  is  consistent  with  Precedes(H),  and  since  e  ■  <r,X,P>,  it  follows  from 
the  definition  of  Precedes(H)  that  (QJO  €  Precedes(H)  for  all  Q  e  Committed(H).  Note  that  A,  * 
OpSeq(Serial(KlCi,T)),  since  P  t  C{. 

Since  P  is  executing  a  response  event,  and  H  is  well-famed,  no  commit  event  fa  P  appears  in 
H.  Also,  C2  is  chosen  such  that  Cj  c  Active;  thus,  if  Q  €  Cj,  no  commit  event  can  appear  in  H 
for  Q.  It  is  an  immediate  consequence  of  the  definitions  that  P  and  Q  are  unrelated  by 
Piecedes(H).  Thus,  by  Lemma  14,  no  operation  in  OpSeq(HlP)  conflicts  with  an  operation  in 
OpSeq(HIQ)foranyQE  Cj.  By  the  definition  of  kj,  no  operation  in  OpSeq(HtP)  conflicts  with 
an  operation  in  Aj. 

We  show  that  hj  •  hj  and  ht  •  OpSeq(HIP)  are  both  legal.  Since  no  operation  in  OpSeq(HIP) 
conflicts  with  an  operation  in  Aj,  it  then  follows  from  Lemma  4  that  ht  •  OpSeq(HIP)  •h2u  also 
legal,  giving  the  desired  result. 

To  show  that  hj  •  hj  is  legal  we  note  that  it  is  simply  OpSeq(Serial(H>C  -  (P}.T)),  which  is  the 
same  as  OpSeq(Serial(K)C  -  (P)  ,T)).  By  the  induction  hypothesis,  this  sequence  is  legal. 

To  show  that  A;  •  OpSeq(HIP)  is  legal  note  that  OpSeq(HIP)  ■  OpSeq(KIP)  •  <ix>  for  some 
invocatioD  i.  By  induction,  hj  •  OpSeq(KIP)  is  legal,  since  it  equals  OpSeq(aerial(K)C,u{P},T)). 

By  the  precondition  for  e,  <lr>  does  not  conflict  with  any  operation  in  OpSeq(HlQ)  for  any  Q  e 
Active;  thus,  ViewfP^)  contains  all  operations  of  ht  •  OpSeq(KIP)  with  which  <i  f>  conflicts. 

Since  e  is  a  response  event  fa  P,  (Q.P)  €  Precedes(H)  for  all  Q  e  Committed(H).  Since  T  is 
consistent  with  Known(H),  K,  C,  and  T  satisfy  the  hypotheses  of  Lemma  IS,  which  then  implies 
that  View(P,sK)  is  a  Coit/Zfcf-cIosed  subsequence  of  ht  •  OpSeq(KIP).  By  the  precondition  fa  e, 
ViewCP^)  and  ViewfP^)  •  <i/>  are  both  legal,  hence  by  Lemma  7,  so  is  ht  •  OpSeq(KIP)  • 

<lr>  *  hj  •  OpSeq(HlP). 

□ 

The  theorem  above  shows  that  a  sufficient  condition  for  LOCK  to  be  correct  is  that  the  conflict  relation  be  a 
dependency  relation.  We  now  show  that  this  is  also  a  necessary  condition. 

Theorem  17:  If  the  conflict  relation  used  in  LOCK  is  not  a  dependency  relation  fa  Serial,  then  L(LOCK) 
contains  a  history  that  is  not  online  hybrid  atomic. 

Proof:  If  the  conflict  relation  is  not  a  dependency  relation,  choose  sequences  A  and  k  and  an  operation  p 
such  that  A  •  p  and  A  •  1  are  legal,  no  operation  in  k  conflicts  with  p,  and  A  •  p  •  A  is  not  legal.  Consider 
the  following  scenario.  Transaction  P  executes  the  operations  in  h  and  commits,  Q  executes  p,  and  R 
executes  die  operations  ini.  By  hypothesis,  p  does  not  conflict  with  any  operations  executed  by  R.  If  Q 
commits  with  a  lower  timestamp  than  R,  the  accepted  history  is  not  serializable  in  timestamp  order.  □ 


6.  Compaction 

Although  the  use  of  intentions  lists  facilitates  our  proofs,  it  has  the  disadvantage  that  object  representations  are 
neither  compact  na  efficient.  Fa  example,  the  size  of  a  Queue  representation  has  no  relation  to  the  number  of 
items  present  in  die  queue,  and  the  item  at  the  head  of  the  queue  must  be  found  by  a  linear  search.  These  problems 
can  be  alleviated  by  replacing  intentions  lists  with  more  compact  and  efficient  representations.  Fa  example,  we  can 
replace  a  sequence  of  operations  with  the  state  (a  version)  that  results  from  applying  those  operations  to  the  initial 
st ate.  Fa  a  Queue  a  Semiqueue,  t  version  might  be  represented  by  an  array  a  a  linked  list,  while  fa  an  Account 
an  integer  cell  might  be  used. 

In  this  section,  we  describe  a  general  technique  for  discarding  intentions  lists  for  commuted  transactions,  replacing 
them  with  the  version  that  represents  their  net  effect  Each  object  keeps  track  of  an  operation  sequence  that  forms  a 
prefix  for  every  view  that  will  henceforth  be  assembled  by  any  transaction.  Each  view  is  assembled  by  appending 
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acme  sequence.  of  intentions  lists  to  the  common  prefix.  When  a  committed  transaction  is  sufficiently  old.  it  can  be 
“forgotten”  by  appending  its  intentions  list  to  the  common  prefix,  discarding  both  its  intentions  list  and  its  commit 
timestamp.  This  common  prefix  is  represented  compactly  as  a  version. 

It  is  important  to  realize  that  a  transaction  cannot  necessarily  be  forgotten  as  soon  as  it  commits,  because  intentions 
lists  most  be  TP""***  10  die  common  prefix  in  commit  timestamp  order,  but  commit  events  for  concurrent 
transactions  need  not  occur  in  timestamp  order.  Instead,  care  must  be  taken  to  ensure  that  a  transaction  is  forgotten 
only  wfaea  no  active  transaction  can  commit  with  an  earlier  timestamp.  To  recognize  when  it  is  safe  to  forget  a 
transaction,  we  introduce  some  auxiliary  compoaeats  to  our  state  machine.  S.clock  keeps  trade  of  die  latest 
observed  commit  timestamp;  it  has  an  initial  value  of -•».  S.  bound  a  a  partial  function  from  transactions  to  commit 
timestamps,  initially  undefined  for  all  transactions.  If  Q  is  an  active  transaction,  s.bound(Q)  is  a  lower  bound  on  the 
possible  commit  timestamps  that  Q  could  choose  when  it  commits. 

We  add  the  following  postconditions  to  the  transitions  for  LOCK: 

<W.Q> 

Postcondition: 

Abound  -  s’.bound{Q  -*  sxlock] 


<rXQ> 

Postcondition: 

Abound  ■  s’.boundtQ  -»  sxlock] 


<commit(t),X,Q> 

Postcondition: 

sxlock  -  max(s’xlock4) 

Abound  ■  s’.bound[Q  -» 1] 

<abort,X,Q> 

Postcondition: 

Abound  «  s’.bound[Q  ->  1] 

These  additional  components  have  no  effect  on  L(LOCK);  they  serve  only  for  bookkeeping.  The  idea  is  that  we 
maintain  a  local  clock  dial  equals  the  maximum  of  the  commit  timestamps  for  transactions  that  have  committed  at 
the  object  Since  the  commit  timestamp  order  is  required  to  be  consistent  with  die  precedes  aider  at  each  object,  the 
lower  bound  on  the  commit  timestamp  for  an  active  transaction  is  increased  to  the  cmeat  dock  time  whenever  the 
transaction  invokes  an  operation  or  has  an  operation  return.  If  Q  is  active  and  <*X,Q>  occur*  then  by  the 
constraints  on  commit  timestamps  the  timestamp  eventually  by  Q  must  be  greater  the  commit 

timestamp  for  any  transaction  committed  ax  X  at  the  time  that  <*X,Q>  occur*  and  similarly  for  <r,X,Q>.  Thus,  the 
caneat  dock  time  when  <*X,Q>  or  <r,X,Q>  occurs  does  constitute  a  lower  bound  on  the  comant  timestamp 
eventually  chosen  by  Q. 

Before  describing  details  of  how  intentions  lists  are  compacted,  we  present  some  properties  of  Abound  and  sxlock. 
We  start  with  a  simple  lemma  relating  these  auxiliary  components  of  LOCK  to  the  ntt~r  components.  The  proof 
involves  a  simple  induction  on  the  length  of  histories  in  L(LOCK),  and  is  omitted. 

Lcanan  It:  Let  Q  be  a  transaction,  Ha  history  in  L(LOCK),  and  a  the  state  of  LOCK  after  accepting  R 

1.  If  Afeoand(Q)  is  defined,  there  exists  a  transaction  P  such  that  sxommitted(P)  -  Abouad(Q). 

2.  If  axommiaedCQ)  is  defined.  sxommitted(Q)  £  Adock. 

3.  If  Acoramiaed(Q)  is  undefined  and  s.intenrioM(Q)  *  A,  then  &houad(Q)  is  defined. 

The  fallowing  tenant  describes  how  s.bomid  and  Aoonwwitted  give  information  about  Kaown(H);  In  particular,  it 
(M|e*ar  with  foe  first  part  of  Lemma  18)  shows  that  *botmd(Q)  is  a  lower  hound  on  Q's  eventual  commit 
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Lemma  19:  Let  P  and  R  be  transactions,  H  a  history  in  L(LOCK),  and  s  the  stale  of  LOCK  after  accepting 
H.  If  s.bound(R)  and  8xommitted(P)  are  defined  and  a.commined(P)  S  s.bound(R),  then  (P.R)  e 
Known(H). 

Proof:  By  "Mt™***™  on  the  length  of  H.  The  result  is  immediate  when  H  is  empty.  For  the  inftnrtvw  step, 
let  H  ■  G  •  e,  where  e  is  a  single  event,  and  let  s'  be  the  state  after  G,  and  s  the  state  after  H.  Fix  a  pair  of 
transactions  P  and  R.  If  e  is  associated  with  any  transaction  other  than  Por  R,  the  values  of  s.bound(R)  and 
axommitted(P)  are  unaffected.  The  result  holds  vacuously  if  e  is  an  abort,  invocation,  or  response  for  P, 
because  axommittedCP)  is  undefined.  The  result  is  also  vacuous  if  e  is  an  abort  or  commit  for  R,  because 
s.bound(R)  is  undefined.  If  e  is  an  invocation  or  response  for  R,  then  s.bound(R)  ■  txlock  2 
gjCommiaed(P),  by  Lemma  18.  Moreover,  (P.R)  e  Known(H),  since  R  executed  an  invocation  or 
response  after  P  committed.  Suppose  e  is  <cotnmit(t),X,P>.  If  t  >  s.bound(R),  the  result  holds  vacuously. 
Otherwise,  by  Lemma  18,  there  exists  a  transaction  Q  such  that  sxommitted(Q)  -  s.bound(R).  By  die 
induction  hypothesis,  (Q.R)  6  Known(G),  and  since  Known(G)  c  Known(H),  (Q.R)  €  Known(H). 
Suppose  axommitted(P) «  acoaumdedCQ);  then  P  ■  Q  (by  well-formedness),  and  by  induction  (P.R)  e 
Known(H).  Otherwise,  s.committed(P)  <  sxommitted(Q),  so  (P,Q)  e  TS(H),  and  thus  by  transitivity  we 
have  that  (P.R)  e  Known(H).  □ 

Now  we  deacribe  how  intentions  lists  are  compacted.  Let  she  a  state  of  LOCK.  Informally,  the  horizon  time  for  s 
is  a  lower  bound  on  die  commit  timestamp  that  can  be  chosen  by  an  active  transaction.  The  result  of  concatenating 
the  intentions  lists  of  all  transactions  whose  commit  timestamps  precede  the  horizon  time  is  certain  to  be  a  prefix  of 
every  transaction’s  view,  and  thus  can  be  compacted  into  a  version.  More  formally: 

Definition  20:  sJurizon  ■  max(  —>,  min(  min(s.bound(P)  I  s.bound(P)  *  1), 

max  ( s.committed(P)  I  s.committed(P)  *  1)  )  ) 

In  other  words,  the  horizon  time  is  either  -»  (if  there  are  no  active  or  committed  transactions),  or  it  is  the  smaller  of 
the  smallest  bound  for  an  active  transaction  and  the  largest  commit  timestamp  for  a  committed  transaction.  If  there 
are  no  active  transactions,  then  die  horizon  timestamp  is  the  largest  commit  timestamp.  If  there  is  an  active 
transaction,  however,  all  we  know  about  its  eventual  commit  timestamp  is  that  it  will  be  bigger  than  the  recorded 
lower  bound  for  the  transaction,  so  we  should  not  compact  intentions  lists  for  committed  transactions  whose 
timestamps  are  bigger  than  that  lower  bound. 

Let  Q^-.Q,  be  the  sequence  of  transactions  for  which  s. commit  is  defined,  indexed  in  timestamp  order,  and  let 
Qi~~.Q^  be  the  subsequence  of  transactions  such  that  sxocnmiKQ^  S  s.horizon.  We  define  the  following 
“auxiliary"  components. 

Definition  21: 8.permanent  ■  sJntentiotu(Qj)  • ...  •  intentions(C^) 

Definition  22:  s.common  -  sjntentionsfQ,)  • ...  •  intentions^) 

Clearly,  s.common  is  a  prefix  of  s. permanent.  To  compute  the  response  to  an  invocation  for  Q,  we  need  to  compute 
View(s,Q).  If  Q  is  an  active  transaction,  then  View(s,Q)  -  ». permanent  •  gJntentions(Q),  of  which  sxommon  is  a 
prefix.  Thus,  s.common  can  be  compacted  into  a  single  version.  To  show  that  this  is  true,  we  show  that  sxommon 
grows  monotonicaUy. 

Lemma  23:LetH-G»ebea  history  in  L(LOCK),  and  let  Sq  and  Su  be  states  of  LOCK  after  G  and 
R  Then  aQXommon  is  a  prefix  of  tH^ommon. 

Proof.  If  e  is  an  invocation,  response,  or  abort  event  for  Q,  then  sH.comntitted  -  sQ.cammitted,  and 
t|,2x»nd(Q)  either  equals  s0.bound(Q),  becomes  larger  than  SQ.boundCQ),  or  becomes  J_  Regardless, 
sHJhorizon  2  Sq  .horizon.  Since  sH.committed  ■  Sq  .committed,  sc  .common  is  a  prefix  of  sHxominon. 

If  « is  a  commit  event  for  Q,  there  are  two  cases.  If  t  is  the  first  commit  event  for  Q,  so  SQ.common  is  a 
prefix  of  Sgxominon.  Otherwise,  SQ^ommon  ■  sH.coounon.  □ 

The  following  theorem  follows  easily  from  the  above  lemma. 

Theorem  24:  Let  0  and  H  be  histones  in  L(LOCK)  such  that  O  is  a  prefix  ofH,andletsaandsHbe 
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state*  of  LOCK  after  O  and  H.  Then  SQ-cemmon  is  a  prefix  of  s^xcnman. 

«?«— grows  monotonically,  we  can  represent  it  by  keeping  a  rente  s-vcrste  and  periodically 
computing  a  new  version  by  applying  (in  commit  timestamp  order)  fee  intentions  lists  for  transactten  P  wife 
s.boond(P)  S  sJwrizcn  to  s. version. 

It  is  not  always  necessary  to  keep  explicit  track  of  transactions'  lower  bounds.  For  example,  if  one  operation 
canflicts  wife  every  other  operation,  as  Peg  does  in  Hgae  4-2  (ignorfag  fee  reftaentanBreeiit  retet), feenaM 
o—nted  traneactione  be  whenever  »  rtetp*»mi»g  tamaaoste  ********  TmmaknQwy 

acquire  a  Deq  lock  only  if  no  afeer  acti re  transaction  has  executedsmy  operations,  implying’ feat tMmnUf)  *  lfor 
all  P  itjwinrt  from  Q,  and  heace  shorten  -  abound(Q).  Ike  committed  Mate  of a  queue  can  be  represented  as  a 
single  coaaasted  version  together  wife  a  set  of  intentions  consisting  enfeetynf  Bag  operations.  Tfco.fee  size  of 
fee  represesaation  would  be  proportional  to  the  number  of  elements  in  fee  qoeae. 

The  Queue  conflict  relation  shown  in  Figure  4-3  can  also  be  rperiaHy  opriaaimi  Here,  aD  opmater  feat  do  net 
conflict  commute,  feat  a  tranaaction  can  be  forgotten  as  aoon  as  it  commits  at  an  object  Ike  vesSMng  aCheme  is 
equivalent  to  a  commutativity-based  locking  scheme  of  Weihl  [22, 25], 


71  Comparison  With  Commutativity-Baaed  Schemes 

As  mentioned  above,  the  precedes  order  captures  potential  “information  flow"  between  transactions.  Most 
mechanisms  baaed  on  twopfaaje  locking  ensure  feat  transactions  are  aeriaiiaable  in  every  total  order  consistent  wife 
precedes,  a  property  known  as  dynamic  atomicity  [22,23].  Conflict-based  concatwncy  normal  mechanisms  for 
dynamic  atomicity  include  those  proposed  by  Etwaran  et  al  [5],  Korth  [13],  Bernstein  et  al.  [2],  and  Weihl  [22, 25], 
These  mechanisms  an  all  baaed  an  a  notion  of  commutativity.  Informally,  two  operations  comwate  if  execntiiig 
them  a  either  order  always  yields  fee  same  results  and  fee  same  final  object  stale.  If  two  operations  do  not 
commute,  their  locks  mast  conflict. 


We  now  afaow  that  “failure  to  commute"  h  a  dependency  rebate,  aflbough  not  uecesstifty*  minimal  dependency 
relatte.  It  follows  feat  our  protocol  is  lam  restrictive  thsn  fee  cammasri  liy-braod  protocol  died  above;  our 
protocol  can  achieve  at  least  as  mnch  ooncwcrency.  Onr  es—ptos  show  feat  iatk  conflict  rtiaiwu  iradoced  by 
dependency  nay  be  weaker  than  or  incomparable  to  those  induced  by  the  coaramrativity  baaed  protocols. 


We  use  fee  following  notion  of  commutativity  taken  from  [22],  a  notion  feat  encompasses  both  partial  and  non- 


Defhiitte  25:  Two  operation  sequences  h  and  A’  are  equivalent  if  they  cannot  be  distiaguifeed  by  any 
future  computation:  A  •gu  legal  if  and  only  if  h’  »g  is  legal  for  ail  operation  sequences  g. 

Dyffehte  26:  Two  operations  p  and  q  commute  if  for  til  operation  anpmmir  A,  whenever  A  •psntl  A  •  q 
are  both  legal,  then  A •  p*  q  and  A  •  q  •  p  are  legal  and  equivalent. 

Unman  27:  IT  A  •  pa ad  A  •  fare  legal  operation  mqnenoea  and  p  coaamntm  wife  ovary  operation  in  A, 
then  A  •  p  •  A  and  A  •  A  •  p  are  lagti  and  equivalent. 

Proof:  By  induction  on  the  number  of  operations  in  A.  The  resalt  is  trivial  when  A  is  empty.  For  fee 
infeirfemiterapproef-f1  wfatreqti  a  ringte  operation,  and  asssrac  fee  result hOKsTer  A*.  Then 
by  induction,  A  *p  •  A’  is  legal  sod  equivalent  to  A  •  A*  •  p.  ByhypofesMi.A-A'^q  (*  A  a  A)  is  legal 
Steep  and  q  commute,  A*  A'  •pvqh  legal  and  equivalent  to  A*  A’-aq*p.  The  tear  is  jntt  A*  t*  p. 
The  former  is  equivalent  to  A  «p*  A*  •  q,  since  A*  A' »p  is  equivalent®  A  *p*  A'.  Bat  this  is  just  A  *p* 
A.  o 
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Theorem  2&  “Failure  to  commute”  is  a dependency relation. 

Proof:  Let  AC  denote  Mure  to  commuiB.  Let  h  and  k  be  operation  sequencer  and  let  p  be  an  operation 
such  that  h»k  and  h»p  are  legal,  and  such  that  for  all  q  in  k,  ( qj> )  c  NC.  It  suffices  to  show  that  h»p»k  is 
legaL  This  is  Immediate  from  Lemma  27.  □ 

Lock  conflict  relations  induced  by  dependency  may  be  weaker  than  or  incomparable  to  those  induced  by 
commutativity.  For  example,  consider  an  Account  object  Commutativity-based  protocols  impose  a  lock  conflict 
relation  that  tnclmfee  (at  least)  die  conflicts  shown  in  Figure  7-1.  This  conflict  relation  permits  strictly  less 
concurrency  than  the  dependency  relation  shown  in  Figure  4-5.  The  additional  restrictions  arise  because  die 
commutativity-based  protocols  require  Post  operations  to  conflict  with  Credit  and  Debit  operations,  while  the 
dependency-based  protocols  do  not.  hi  the  Queue  example,  by  contrast,  the  commutativity-based  protocols  induce 
lock  conflicts  identical  to  those  induced  by  the  minimal  dependency  relation  shown  in  Figure  4-3.  Here,  however, 
the  commutativity-based  protocols  do  not  permit  the  incomparable  conflict  relation  induced  by  the  minimal 
dependency  relation  in  Figure  4-2. 


CreditOO.Ok 

Post(n),Ok 

Debit(n),Ok 

Debit(n),Overdraft 

Credit(m),Ok 

true 

true 

Post(m),Ok 

true 

true 

true 

Debit(m),Ok 

true 

true 

Debit(m), Overdraft 

true 

true 

Figure  7-1:  “Failure  to  Commute”  Relation  for  Account 


hi  addition  to  requiring  fewer  conflicts  than  commutativity-based  protocols,  our  work  also  generalizes  most  other 
weak  on  type-specific  two-phase  locking  by  allowing  the  results  returned  by  an  operation  to  be  used  in  choosing  the 
appropriate  lock,  and  by  permitting  operations  to  be  partial  and  non-detetminisric.  Some  other  protocols  (e.g., 
see  [18])  achieve  the  effect  of  using  information  about  results  by  acquiring  a  restrictive  lock  when  an  operation 
starts  running,  and  then  “down-grading”  the  lock  depending  on  how  the  operation  actually  executes.  The  resulting 
protocol  violates  two-phase  locking,  and  as  a  result  ad  hoc  correctness  arguments  are  usually  given.  Our  protocol 
shows  how  the  results  of  an  operation,  as  well  as  names  and  arguments,  can  be  used  systematically  to  determine  the 
lock  needed.  (The  commutativity-based  protocols  in  [22, 25]  also  permit  result  information  to  be  used  in  choosing 
locks.) 

In  addition,  other  protocols  (except  for  those  in  [22, 25])  require  operations  to  be  total  and  deterministic.  Partial 
operations  are  important  for  modeling  producer-consumer  relationships,  in  which  one  transaction  is  consuming  data 
produced  by  another.  Such  situations,  while  perhaps  uncommon  in  traditional  database  applications,  are  more 
common  in  general  distributed  or  object-oriented  systems.  Similarly,  non-deterministic  operations  are  an  important 
source  of  concurrency;  compare,  for  example,  the  dependency  relations  for  Queue  and  SemiQueue  shown  earlier. 
(Non-determinism  can  also  increase  availability;  see  [8]  for  an  example.) 

Another  way  in  which  our  work  differs  from  most  other  work  on  type-specific  concurrency  control  is  in  the 
treatment  of  recovery.  With  the  exception  of  [22, 25],  the  other  work  ignores  recovery. 

A  more  general  form  of  hybrid  atomicity  is  defined  in  [22, 23],  permitting  read-only  transactions  to  be  treated 
specially,  as  in  (he  multi-version  protocols  in  [3, 4, 24],  Timestamps  for  read-only  transactions  are  chosen  when 
they  start,  while  timestamps  for  other  transactions  are  chosen  when  they  commit  This  algorithm  is  the  origin  of  the 
term  “hybrid  atomicity,”  since  the  protocols  combine  aspects  of  dynamic  atomic  protocols  (such  as  common 
two-phase  protocols)  and  static  atomic  protocols  (such  as  Reed’s  multivmiou  protocol).  In  fact,  hybrid  atomicity  is 
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upward  compatible  with  dynamic  atomic  protocols:  dynamic  atomic  protocols  guarantee  serializability  of 
committed  transactions  in  all  total  orders  consistent  with  Precedes(H);  since  TS(H)  is  one  such  order,  global 
atomicity  is  still  obtained  when  dynamic  and  hybrid  atomic  objects  are  combined  in  a  savgle  system. 

Our  results  suggest  that  dependency  is  a  more  fundamental  property  than  commutativity  for  understanding 
concurrency  control  for  typed  objects.  In  addition,  the  notion  of  a  dependency  relation  arises  in  a  variety  of  other 
related  contexts.1  The  constraints  on  the  availability  realizable  by  quorum  consensus  replication  [g]  can  be 
expressed  in  terms  of  dependency  relations.  Dependency  relations  also  form  the  basis  for  validation  in  type-specific 
optimistic  concurrency  control  mechanisms  [9],  as  well  as  type-specific  locking  schemes  baaed  on  multi-version 
timestamping  [10],  and  schemes  that  provide  high  levels  of  availability  in  the  presence  of  partitions  [11]. 

To  summarize,  we  have  defined  a  new  locking  protocol  that  permits  more  concurrency  than  existing  commutativity- 
based  protocols.  It  permits  operations  to  be  both  partial  and  non-deterministic,  and  it  permits  results  of  operations  to 
be  used  in  choosing  locks.  The  protocol  exploits  type-specific  properties  of  objects;  we  have  shown  how  to  define  a 
necessary  and  sufficient  set  of  constraints  on  lock  conflicts  directly  from  the  data  type  specification  The  protocol  is 
optimal  in  the  sense  that  no  hybrid  atomic  locking  scheme  can  permit  more  concurrency. 


L  An  Example  Implementation 

To  illustrate  how  our  locking  protocol  might  be  used  in  practice,  this  appendix  describes  an  implementation  of  the 
Account  data  type  using  Avalon/C-n-  [12],  a  programming  language  that  supports  hybrid  atomicity.  We  assume 
some  familiarity  with  C++  [20].  Although  AvaloWC++  supports  nested  transactions,  this  example  assumes  only  a 
single-level  transaction  model. 

We  stan  by  describing  the  subsidiary  data  types  used  by  the  Account  implementation.  Avalon  programmers  do  not 
manipulate  transaction  timestamps  directly.  Instead,  Avalon  provides  a  trans_14  data  type  to  permit  the 
programmer  to  test  serialization  orders  at  nm-time.6 
elu*  txaa*_id:  potato  naannbl*  { 
pxlmta: 

//  roprosont  >tlon 

priUia: 

tMO»_id()  ;  //  aonatruatox 

bool  opoxotor»(troa«_ld*  olio);  //  aqual? 

bool  opocotoXftroN.Ida  oho);  //  nrUllnd  boforw? 

• • •  //  otbor  opozofclooo 

); 

A  transaction  generates  an  identifier  by  a  call  to  new: 

txona_ld*  oho  *»  aw  trana__id; 

Transaction  identifiers  ate  partially  ordered  by  the  overloaded  operators  “>”  and  “<.”  If  transactions  P  and  Q 
respectively  create  identifiers  tl  and  t2,  then  the  expression 
tl  <  *a 

evaluates  to  true  if  and  only  if  (P,Q)e  Known(H),  where  H  is  the  current  history. 

An  account  object  maintains  lock  information  in  a  lock  table. 

•msa  l°ok_typo  (CMDXTJbOCX,  POtT_LOCX,  NEBXTJbOCX,  OVBDMRJtOCK) ; 


^noSafiaOna  of  a dep—dwey  lahtkn  pvan  in  lh>»  peper a  tttfd  diflonaty  front  Ihn  fa  other  paper!  by  Hertihy.  bat  a  etafy  Sow  to  be 
Mlaaa  bool  to  baw  emanation  typa  abb  TRUK  act  to  t  adFJkXtSSaettoO. 
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olut  lockjbeb  ( 
print*: 

public: 

lockJbebO;  //  oocitnotor 

void  d»fin*  (look_typo  nd*0,  //  x*gi*t*r  a  leak  eon  flint 

loakjbype  Model) ; 

bool  ooBfliet (lockjtypo  node,  //  ok  to  great  look* 
taujld*  1*0); 

veld  grant (look_type  node,  //  gin  leak  to  cellar 
trmns_ld*  who); 

void  raleaee (tree*  id*  Mho) ;  //  release  caller's  locks. 

); 

The  account  operations  are  represented  by  the  enumeration  type  look_type.  An  empty  lock  table  is  created  by 
declaring  a  variable  of  type  lockjtab,  and  the  define  operation  marks  two  «r»ntfcr«a  as  The 

oonfliot  operation  takes  a  lock  type  and  a  transaction  identifier,  and  returns  true  if  no  other  — holds  a 
conflicting  lock.  The  grant  operation  grants  a  lock  far  a  specified  operation,  and  roloaoa  diacanis  all  locks  held 
by  a  transaction. 

The  net  effect  of  a  transaction  that  executes  moltiple  Credits,  Debits,  and  Boss  is  to  replace  the  balance  b  by  the 
affine  transformation  m*b+a  for  some  m  and  a.  Each  transaction's  intention  it  recorded  in  the  following  struct: 
struct  intact  (float  uni;  fleet  add; 

intent  (float  a,  float  a)  (nul  ■  a;  add  ■  a; )  ; 

1; 

The  last  component  defines  a  constructor  operation  for  initializing  the  struct.  The  mmummmi  associated  with  each 
transaction  is  kept  in  a  cable: 

class  intontjtsb  (  //  nap  trana  ->  intention, 

private: 

. . •  //  representation 

public: 

iufceotJtebO ;  //  oonatruator 

intent  lookup  (trens_id*  <**);  //  return  intention 

void  In  sort  (tren*_id*  Mho,  //  bind  teens  to  Intention 

intent  ubet); 

veld  dieaerd  (trene  id*  ube) ;  //  discard  intention 

I; 

Lookup  returns  a  transaction’s  current  intention.  If  none  exists,  it  returns  an  intention  with  multiplicative  and 
additive  components  1.0  and  0.0  respectively. 

Intentions  for  committed  transactions  are  discarded  using  the  horizon  time  scheme  described  in  Section  6.  Each 
active  transaction  keeps  track  of  the  latest  committed  transaction  guaranteed  to  be  serialized  before  itself.  This 
information  is  kept  in  a  table: 

aloes  boundjteb  ( 
private:  ~ 

public: 
bcuedJbebO; 

void  Insert  (trees  Id*  ube, 
tren*“id*  bed); 
void  discord  (trensjLd*  who); 
trees  Id*  elaQ ;  ~ 

I; 


Transactions  tbat  are  committed  but  not  yet  forgotten  are  kept  in  a  heap. 

°!***  ld_bsep  (  //  sorted  beep  ef  tree sect iocs 


//  esp  trees  ->  lower  bound 

//  represent st low 

//  constructor 

//  register  new  lower  booed 

//  dieaerd  lower  bound 
//  hortmoa  transaction 
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prlvoto: 


// 


paUle: 

id  hoop();  //  ocnst  motor 

tMBi  14*  top() ;  //  rat  am  oldtft  transaction 

fold  Zns«rt(tx«na  Id*  vbo) ;  //  laanrt  transact loo 

bool  mmptfl);  ~  //  ia  h“P  nptyt 

); 


This  data  type  provides  operations  Cor  creating  an  empty  heap,  insetting  a  transaction  identifier  in  the  heap,  nd 
observing  or  removing  the  oldest  (Le..  minimal  with  respect  to  “<")  identifier  in  the  heap. 


We  ate  now  ready  to  examine  die  Account  implementation  itself. 


almas  account:  pobllo  anbato 
pxivata: 

do  { 

lookjtab  looks; 

// 

lntoatjbob  intentions ; 

// 

float  bol; 

// 

idjMop  nnoo Ittod; 

// 

txans  id*  olook; 

// 

boamftab  boondo; 

// 

void  forgot (); 

// 

otafcno  mat t latent  (trooa_ld*  «ho, 
float  ant); 


looks  fox  operation* 
list 


Ittod  bat  unfoxgettoa  txansaotle 
•oont  t  ran*  anti  on  to  oowalt 
oar  Hast  poaalblo  ooooit 
fox  formatting  ooomittad 
//  oevoxs  dabltt 


pobllo: 

vnld  oradit (float  ant); 
bool  dablt (float  ant); 
void  post  (float  ant); 
wold  oomnLt  (trana_ld*  abo); 
void  abort  (txano  id*  abo) ; 
I; 


The  “public  subatomic"  declaration  means  that  this  data  type  (“class”  in  C++  terminology)  inherits  certain 
operations  necessary  far  short-term  synchronisation  and  for  ensuring  that  the  object  is  recorded  properly  on  stable 
storage.  The  object’s  internal  representation  is  given  by  die  fields  following  the  keyword  private.  The  locks 
component  keeps  track  of  the  locks,  intantjtab  recarda  transactions’  iatmtiona.  bal  is  the  account  balance  left 
by  “forgotten"  committBd  transactions,  and  nonmittod  keeps  hack  of  transactions  drat  bane  committed  but  have 
not  yet  been  forgotten.  The  internal  function  forgot  race  the  dock  raid  bound*  fields  to  iraplrsnrnl  the 
nranjur^uw  rhHM  described  in  Section  6.  The  in— i  tmrtirm  suffioiant  deterntinca  whather  the  balance 
coven  an  attempted  debit  by  a  particular  mraaction. 


When  an  account  is  created,  the  account  conatnictor  is  invoked: 

pinning ()  (  //  ashing  update 

olook  “  dm  tnun_id;  //  olook  is  orootor's  id 

bol  a  0.0;  //  bozo  initial  bolanoo 

//  Sat  up  look  oanflioto. 

look* . dofioo (C3SDZT  LOCK,  OVmONkfT  LOCK); 

looks. dofioo (POST  LOCK,  OVBBXIR  LOCK); 

looks. doflao(DnXT  LOCK,  BHMR  LOCK)  ; 

1 

) 

To  ensure  proper  crash  recovery,  all  modifications  to  the  object  mot  occur  inside  a  pinning  statement  Most  of 
the  object’s  members  are  implicitiy  initialised.  The  clock  is  initialised  with  tira  creator’s  identifier,  the  balance  is 
iaitiaiisBd  to  aero,  and  the  lock  table  is  initiaUaed  with  dtc  conflict  relation  ahown  in  Figure  4-5. 
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The  Credit  taction  Is  implemented  as  follows, 
void  vuord:  :«ndlt{flMt  sat)  { 
tnn.'  id*  tdo  ■  dm  trans  Id; 

(Am  7 I  looks .  ooofliot  (CSXDIT_LOCX,  who)) 
planing!)  { 

looks,  grant  (CBB>XT_LOCX,  who); 
intant  1  -  latantlons. lookup (who); 
l.add  -  l.add  +  aat; 
intontioos . insert (who,  1); 
bounds .  insert  (who,  olook); 

) 


//  Oat  oallor'a  id. 

//  Chaok  for  ooofliot. 

//  Making  updato. 

//  Aogulns  look  . . . 

//  and  currant  istantloo. 

//  tooord  orodlt  . . . 

//  and  rogiator  now  intent loo. 
//  Meta  aaw  bound. 


) 

atonic  object  has  an  sssoriMrri  mutual  exclusion  lock,  similar  to  a  monitor  lock.  Use  wham  statement  is 
similar  to  a  guarded  command.  It  repeatedly  acquires  the  lock  and  evaluates  the  condition.  If  the  condition  is  true, 
the  associated  statement  is  executed  and  the  lock  is  released.  Otherwise,  the  lode  is  released  and  the  condition  is 
retried  after  an  arbitrary  rfimAai  The  Credit  operation  generates  an  identifier  for  the  caller,  and  checks  for  lock 
conflicts.  If  none  is  found,  the  caller's  intention  is  updated,  and  the  current  dock  value  is  recorded  as  the 
transaction's  new  bound.  The  Poet  operation  is  similar,  and  is  omitted. 


Debit  is  slightly  more  complex. 


bool  ssooBat : : dobifc (float  auk)  ( 
trams  Id*  who  -  aw  tnaa  14; 
whanawltoh  (aufflolant  (who,  «*)){ 

nmaai  * 

OHM  • 

pinning!)  ( 

looks. grant (mXSJMCX,  who)  ; 
Iataofe  1  m  intentions . lookup (who) ; 
l.add  ■  l.add  -  ant; 
intentions . insort (who,  1); 
bounds. laaart (who,  olook) ; 
mtnsn  XROS; 


1 


//  Oat  oallor'a  14 

//  (Mbit  ok 
//  Making  qpdato. 

//  Aoqulro  look  . . . 

//  find  latantlon  . . . 

//  rnoord  dablt  . . . 

//  and  ragistor  aaw  latantlon. 
//  Meta  aaw  bound  . . . 

//  and  rot ora  nuoooaa  ooda. 

//  Ok  to  rnfaso  dablt. 


planing!)  !  //  Making  updato. 

looks. grant (CWnOMWT_Z0CX,  who);  //  Aogoiro  look  ... 

) 

) 

I 

The  whauwUck  statement  is  a  geoemBation  of  the  when  itstemrnt  that  rephoes  the  baokun  expression  with  an 
expression  of  an  enumeration  type.  Here,  Debit  calls  upon  the  internal  procedure  sufficient,  which  returns  YES  if  the 
account  balance  covers  the  debit,  NO  if  the  debit  should  be  refused,  and  MAYBE  if  lock  conflicts  leave  the  account 
status  ambiguous. 


The  code  for  mffldtnt  sppears  below. 

anon  status  (TBS,  MO,  MUM); 

status  aoooant ; ; sufficient (trans_ld*  who,  float  ant) ( 
float  wiaw  •  bal;  “  //  Construct  rlaw 

Idjbaap  h;  b  o  oomalttod;  //  Copy  heap  of  n anal t tod  Id' a. 

wkila  (th.aavtyO)  <  //  Apply  aaoh  oosndttod  latantlon. 

Intant  1  o  Intentions, lookup (h.ranowa ()); 

▼law  o  l.aal  *  vlow  +  l.add; 

1 

Intant  1  ■  lntootloos . lookiqp (who);  //  Apply  oallor'a  lafeantlao. 
▼law  o  i.sml  *  vUw  +  l.add; 


//  Sofflaiaat  funds? 
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If  (via*  »  at  U  I  looks .  oonf  liot  (DEBXT_LOCK,  who))  ntsn  TBS; 


//  Xnouffieiont  fond*? 

if  (viow  <«at  II  I  looks .  oonf  Hat  (OVnDMkRJbOCK, 


) 


// 


t  tall. 


*bo>) 


Atomic  objects  in  Avalon/C++  provide  commit  and  abort  operations,  which  are  called  by  (he  system  when 
transactions  commit  or  abort.  The  commit  operatioa  for  Account  is  the  following: 


wold  aooount ; ; oonnit (trensid*  wbo){ 


ebon  (BtOB) 
plnnlngQ  ( 

if  (*oloek  <  *who)  aloak 
looks .  MlttM  (who)  ; 
bounds . discard (who) ; 
■meal t tod.  insert  (who)  ; 
forgrtO; 


//  Always  ok  to  ooaoi 
//  Updating  objoot. 
who;  //  Advaaoa  aloak. 

//  tlslsa—  looks. 

//  Discard  bound. 

//  Mark  aa  oosssittod. 
//  Try  to  forgot. 


t. 


} 


) 


The  clock  is  advanced,  the  committing  transaction’s  locks  are  released,  its  lower  bound  is  discarded,  die  transaction 
is  marked  as  committed.  Tbe  internal  function  forget  is  called  to  forget  committed  transactions: 
void  aoooont : :  forgot  ()  ( 

trsns_id*  borlson  -  bounds .ala () ; 

wbila  ( t  ooenittod .  aapty  ( )  ||  *  (ooasd.tted.top  ()  )  <  *horixoa)  ( 
trsns_id*  t  ■  nn— Ittod.  rsann () ;  //  tarns  tho  transaction. 

In  toot  i  s  intentions,  lookup  (t);  //  find  its  intention, 

faal  -  l.anl  *  bal  +  i.add;  //  apply  it, 

intentions . dlaonrd (t ) ;  //  end  diaonrd  It. 

> 

> 

This  function  recomputes  the  hariaon  time,  and  applies  and  discards  tbe  Intentions  for  all  wwnminnri  transactions 
aerialusd  before  the  horizon. 


Abort  is  similar  to  commlr. 


void  aoooont : : abort  (trans  id*  wbo) ( 
whan  (BUM) 
pinning ()  ( 

looks,  release  (who) ; 
bounds . diaaard (wbo) ; 
intent  ions,  discard  (wbo) ; 
forgot  (); 

) 


//  Always  ok  to  abort. 
//  Updating  Object. 

//  Release  looks. 

//  Diaaard  bound. 

//  Diaaard  iat nations. 
//  fry  to  forget. 
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